hi bruno,
i am in the middle of testing a sema.bin that i believe fixes the problems you
have found.  the problem was an uninitialized variable in the 56000 firmware
in the Vibrato SCAs, which had to do with timing the output of decimated
samples from these SCAs.  It was possible for different SCAs to get out of
sync such that their outputs would not be at the same exact time .... the DMA
interrupt is generated by ORed the OUTPUT_VALIDs of all SCA, thus, when they
got out of sync, no interrupt was generated .... giving the DMA_TIMEOUT 
error.

i will replace the sema.bin on hpls01 in the bruno directory with this new
one that i think will fix your problem.  i am running a script that 
continuously runs your control.c program .... it has been running for over
1/2 hour now with no errors ... the most i could get before this fix was about
2-3 minutes.  i will leave it run overnight, but after another 1/2 hour i
will go home.  so, you should try this sema.bin ... it should be compatible
with x2.06 or x2.05 and maybe x2.04, but i wouldn't count on that last one.

Whoops!!!, just had a DMA error, but not for the same reason as before ... i 
checked all of the SCAs on the module with an oscilloscope and their outputs 
are in sync.  this is new, different, problem.  it took over 1/2 hour of 
continuously starting up the module for this error to happen; so i still 
think you should give the sema.bin a try, it will most likely work just 
fine for your acceptance test.

it will take me some more time to track down this new problem ... let me know
how this new sema.bin works.  the zoom code was just finished recently and
was just starting to get some QA time at the beginning of this week; so
it is a little rough yet.  we are planning another official release in march;
we will be spending several weeks in QA before this release; so the code will
be solid then.

hope everything works well for you, i know it is hard to deal with the
factory sometimes, because we have difficulty keeping our schedules.
doug   
